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The present invention relates, generally, to secure network communications and, in 
5 particular, to methods of cormnunication between a client connected to an external 
network and a seivice provider on a private network via a gateway bridging the private 
and external networlcs. The client may be connected to its own private network bnt such 
a private network, and a public network, eg the internet, by which the client 
communicates with the service provider, are all considered an external network relative 
10 to the service providers private network. 

ftartrgrniiTiri nf the Tnvention 

An example of such connected networks is one in which the private network of the 
service provider is connected to the internet by a gateway acting as a '^firewall" to 
15 protect the private network from lujwanted intrusion from users on the internet. The 
gateway is designed to allow only authorised messages to pass from one netwoiic to tl\e 
other via itself A client on the external network wishing to communicate with the 
service provider on the private network will first be connected to the gateway which wiU 
usually establish the credentials of the chent and whether the client is authorised to 

2 0 communicate with the service provider. If authorised, communications are then 

established between the client and service providear via tlie gateway which flmctions as a 
relay for the client-service provider communications. 

The routing of messages received by the gateway to the service provider can be carried 
25 out in a number of ways and perh^s with one or more security measures applied by the 
gateway, A known approach to routing messages to the service provider is to hide the 
identification of the service provider on the private network from the client and for the 
gateway to re»map messages received from client to the service provider, prior to 
forwarding them onwards, by modifying the to address in the message destined for the 

3 0 service provider to be the private network address of the service provider. 
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If the service provider wishes to advertise to the client another service or service 
provider^ the gateway can be arranged to read the reference in the message being passed 
to the client, substitute a virtaal name for the real name, store tlie cross-reference to the 
5 real name of the other service provider^ and relay the modified message to the client. 
The virtual name is also bound to tJie gateway so messages addressed to the virtual name 
will be routed to the gateway. The gateway then re-maps received messages to this 
other service or service provider using the stored cross-reference. In this way the real 
name of the service providers on the private network are kept fi-om the chent on the 
1 0 external network so enhancing the security of the private network. 

It will be appreciated that these so called application gateways require the gateway to 
understand the protocol being employed by tlie client and the service provider so the 
messages can be read, the re-mapping cross-references stored, and the message 
15 appropriately modified by the gateway to provide the relaying of messages from one to 
the other. 

Another approach is tl:Le circuit level gateway in which a client establishes an authorised 
connection to the gateway using a first protocol which first protocol is then used to 
2 0 encapsulate messages in a second protocol destined for the service provider. The 
gateway receives the encapsulated messages and forwards them to the service provider 
having extracted them from the first protocol messages as received from the client. This 
is commonly referred to as a tunneUing. Again, if the gateway can understand the 
messages in the second protocol passing between the client and the service provider, the 

2 5 re-mapping carried out by the gateway can be automatically updated as new services or 

service providers are advertised to clients so, again, providing relaying while keeping 
the real names of the service providers from the client 

Such updating of re-mapping information is not possible, however, if the messages 

3 0 tunnelled between the client and service provider cannot be understood by the gateway, 
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for example, if the turmeUed messages are encrypted for end-to-end security between the 
client and service provider as provided, for example, by tihe system in the applicant's co- 
pending patent application USSN 09/733014 the contents of which are incorporated 
herein by reference in its entirety. 

5 

The present invention has as its primary object the provision of methods in which the 
real names of service providers can be kept hidden firom clients and which is of 
particular, but not exclusive, application to network aixangements in which there is end- 
to-end security between a client and a service provider, 

10 

Summary of the Tnvenlion 

According to a first aspect of the present invention there is provided a method for a 
service provider on a private network to provide a service to an external client on an 
exlemal network via a gateway bridging the private and external networks, includmg the 
1 5 service provider carrying out the steps of: 

allocating a virtual name to the service provider; 

- making the virtual name availab le to the client on the external network: 

- binding the virtual name to the routing address of the gateway on the external 
network; and 

20 - binding the virtual name to the routing address of the sendee provider on the 
private network. 

The client will direct communications to the virtual name of fhe service which by virtue 
of the binding to the routing address of the gateway will be routed to the gateway. The 

25 binding can be elBfected for internet communications, for example, by registering the 
virtual name as an alias of the gateway on pubHcly accessible DNS servers. The 
gateway then forwards the communications onwards using the binding of the virtual 
name on fhe private network which now provides the routing address of the service 
provider. The same vhtual name is used globally for all routing with no requirement for 

3 0 re-mapping of addresses. 
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The virtual name may be bound to tlie routing address of the gateway and the roaling 
address of the service provider by way of an extejTial domain name server and private 
domain name sexver, respectively, A furHier approach is one in which the virtual name 
5 is bound to tlie routing address of the service provider on an internal naming service. 

The method of the present invention has particular appUcabiHty to methods in which the 
client and the sendee provider communicate by way of an encrypted tunnelled session 
via the gateway. 

10 

The present invention may be used in various service provision scenarios. For example^ 
the client may be on a second internal network distinct fiom the internal network of the 
service provider and with a second gateway bridging Ihe second internal network and 
external netwoik. In such a case the method of the present invention may include the 
1 5 steps of: allocating a second virtual name to the client; making the second virtual name 
available to the service provider; binding the second virtual name to the routing address 
of tiie second gateway on the external network; and binding the second virtual name to 
the routing address of tlie cUent on the second internal network. 

2 0 As a furtlier example there may be a second service provider on a second private 

network able to communicate with an external network via a second gateway bridging 
the second private network and the external network. In this case the method may 
include the st^s of: allocating a second virtual name to the second sersnce provider^ 
making the second virtual name available to a chent; binding the second virtual name to 
25 the routing address of the second gateway on the external network; and binding the 
second virtual name to the routing address of the second service provider on the second 
private network. 

The private network of the service provider may be nested within one or more further 

3 0 private networks through which the client may wish to communicate via a series of one 
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or more gateways. In this case the method may include binding the virtual name to 
routing address of flie fiiither gateway on the network external to the further private 
network. 

5 According to another aspect of the present invention, there is provided a metliod of 
providing access to a server on a private network from an external client on m external 
network via a gateway bridging the private and external networks, the gateway 
supporting tunnelling of second messages to said server by encapsulating them in first 
messages routed to the gateway; the method involving: 
10 (a) " allocating a virtual name to the server and mapping it by a first mapping to the 
routing address of the gateway on the external network and by a second mapping 
1 to the routing address of the server on the private network; 

(b) - at said external clieoit, using the virtual name to address a said first message md a 
0 1 said second message, the foimer encapsulating the latter; 

J:{ 15 (c) - using the first mapping to route the first message, with its encapsulated second 
01 message^ to the gateway; and 

'l^ (d) - using the second mapping to route the second message extracted at tlie gateway 

0 1 from the first message, to the server 

y I 

2 0 RH^f nf^srriptinn nf tli^ Drawings 

Embodiments of the invention wil] now be described by way of example only, with 
reference to the accompanying drawings of which: 

Figure 1 is a diagram of an end-to-end communication arraQgement to which the 
present invention may be applied showing details of an embodiment of a 
25 Session Layer Security (SLS) protocol entity used to estabhsh a secure 

session over the conMnunication arrangemeiit; 

Figure 2 is a diagram depicting tunnelling supported by nested sessions established by 
an SLS protocol entity; 

Figure 3 is a diagram illustrating the use of SLS entities in a resource mediation 

3 0 environment; 
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Figure 4 is a diagram illustrating tlie use of an SLS plug-in web bowser for 
establishing a secar(^ session with a resource mediation environment on a 
broker server; 

Figure 5 is a diagram illustrating exposure of a service of a private network to aa 
5 external network, according to the present invention; 

Figure 6 is a diagram illustrating a network arrangement access of providing a service 
of a private network fi»m an external network^ according to the first 
invention; 

Figure 7 is a diagram showing Hie flow of messages in establishing an end-to-end 
1 0 secure communications linlc; and 

Figures 8 to 12 are diagrams of fuitlier network anaugements according to the present 
invention. 

Best Mftdfi ftf Carryine Out thfi Tnvention 

15 Embodiments of the present invention will now be described as applied to a 
communications network in which a client, gateway and service provider communicate 
using a session-layer security protocol, and who for convenience will also be referred to 
as AlicCj Bob and Charlie using the usual general entity naming convention. It should 
be noted, however^ that the present invention is generally applicable to network 

2 0 airatigements ui which a private and public (external) network are bridged by a gateway. 

Figure 1 depicts an end-to-end secure communication path between a client 10 of a first 
end system 1 1 and a target sei^ce 12 of a second end-system 13 which client 10 wishes 
to use. This communication path involves a reliable connection 16 established between 
25 ihe end systems 11, 13 by transport entities of 14, 15 of the two systems. Tlie precise 
details of the transport mechanism used to establish and maintain connection 16 is not of 
importance to the present invention; however^ by way of example, the connection 1 6 can 
be an iaternet TCP/IP connection. Typically, the transport entities 14, 15 are arranged to 
handle multiple simultaneous connections potentially of different types^ and this is 

3 0 represented by arrows 17 in Figure 1. Each connectioa, such as connection 16, may 
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cairy traffic for multiple simultaneous sessions of one or more applications (the client 10 
being one such application) as is indicated by aiiows 18. Hie following description will 
at first focus on the provision of seciiiity for a single secure session betwetai the client 
10 and service 12 over the connection 16, then how a tunnelled end-to-end secure 
5 session via a gateway is established and then how the present invention can be applied to 
such tunnelled sessions as an exemplary embodiment, only of the present invention. 

Security for commumcalion bel^ween cUent 10 and sendee 12 is provided at the level of 
a session by cooperating session-level security ('SLS') entities 20, 30 in end systems 11, 
10 13 respectively, die SLS entity being logically located between the client 10 and 
transport entity 14 and the SLS entity 30 being logically located between service 12 and 
m transport entity 15. Each SLS entity is capable of haadling multiple simultaneous 

Jf : sessions involving different client-service pairings. The protocol operated between the 

p I SLS entities is herein referred to as the SLS protocol, 

01 When the chent 10 wishes to estabhsh a communication session with service, the SLS 

!1 entities first cany out a handshake procednxe the purpose of which is two-fold: 

0 1 - to determine if each party has certain 'attributes' required of it by the other - if this 

I is not the case, then a coromuuication session is not established; and 

5 J ii 

Q 2 0 - to ^change cryptographic data to enable shared keys to be established for the 
communication session being established (if allowed). 
Assuming the handshake was succcssfid, the SLS entities are then responsible for 
operating the resultant secure channel established between the client 10 and service 12. 

2S An 'attribute' expresses some property such as a name, a location, a credit limit, an 
owner or a role. Attributes are proved by certificates that are exchanged and 
authenticated to ensure that neither party (chent or service) is making false claims about 
the possession of an attribute. Whilst the identity of the client or service constitutes an 
attribute, there is no a prion requirement that this attribute must be presented and 

3 0 verified - it is up to the parties (client 10, service 12) to specify what attributes they 
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reqitire of the other. 

In the present an-aagement, attributes are established by SPKJ certificates which are 
explained in detail in C Ellison et al, "SPKI Certificate Theo]y\ IETF RFC2693 
September 1999 and C Ellison et aL, "SPKI Examples", lETT RFC 2692 September 
1999, for example. It should be noted that as uses herein, tie term 'attribute certificate' 
means any signed electronic instniraent bestowing an attribute on the subject of the 
certificate and therefore encompasses both SPKI 'attribute' certificates and SPKI 
'authorization' certificates. 



Proving that a party has a particular attribute means establishing a trust chain of valid 
certificates back to a party inlierently taasted in relation to matters concerning the 
attribute. This trust chain may involve not only attribute certificates but also 'name' 
certificates. In this respect^ it is useful to note that the issuer and subject of an SPKI 
15 certificate is fundamentally a principal constiuited by a public key (or its hash). Of 
coarse^ there ^11 be a keyholder associated with &e public key (tliis being the party 
holding the private key matching the public key) but diat party may not be identified at 
alL The subject of certificate may also be specified by a name but in this case there 
should also name a certificate mapping the name to the correspondiag principal. 



A more detailed discussion of SPKI certificates and their use in providing attributes can 
be foimd in our co-pending USSN 09/732954 entitled "Method and Apparatus for 
Discovering a Trust Chain Inpaitiog a Required Attribute to a Subject" to wliicli 
reference is directed. 



In order to provide the means for implementing the foregoing features, the SLS entity 20 
(and coirespondiugly the entity 30) comprises: 

a certificate services block 21 for providing tmst chaiu discovery and certificate 

reduction services; 

3 0 - a cryptographic services block 22 for providing signature arcation and checking 
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services and exponentiation services during the key-exchange handshake, key 
generation services for generating the session keys for the secure channel 
established following a successful handshalce, and MAC (Message Authentication 
Code) creation checking services and enciyption/decryption services for messages 
5 exchanged over the secm-e channel; and 

- a protocol engine 23 with a key exchange handshake functional block 24, a secure 
channel ftinctional block 25, an SLS PDU processing block 28, and a control 
block 26. 

The control block 26 is responsible for coordinating the oiha: elements of the protocol 
10 engine 23 according to input received from the client 10 and present in the unencrypted 
header fields of messages received over connection 16 via tbe transport entity 14. As 
aheady mentioned, the SLS entity is capable of handling multiple simultaneous sessions 
and the control block 26 is responsible for correctly associating client input and 
messages with the appropriate secure coimiiunication session (or to initiate a new 
15 session if no session currently exists when client 10 requests to communicate with 
services 12); this it does by assigning an identifier to each secure session, this identifier 
being herein called the Security Parameters Identifier (SPI). The SPI is carried in clear 
by messages passed over the secure channel The control block 26 stores information 
relevant to each session, including the related SPI, in a session memory 27 and 
20 whenever the protocol engine receives a message from transport entity 14, it uses the 
SPI to look up the appropriate session data. The session data can also be accessed by 
client ID. Block 29 in Figure 1 indicates the most important data items held for each 
session. 

25 The client holds its own private key 33 used for digitally signing messages during the 
key exchange to authenticate them as originating from itself The signing functionality 
is provided by the cryptographic services block 22, The client also holds it own 
collection of SPKI certificates m certificate Ubraiy 32 from which it can extract the 
certificates appropriate for proving that it has particular attributes. Whilst the client 

3 0 endeavours to keep a record of the chain of certificates appropriate for proving each of 
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its attributes, it can call on the trust chain discovery fianctionality provided by the 
certificate seivices block 21 to help it find such a chain (a suitable foim of trust-chain 
discovery engine is described in our above-mentioned co-pending patent application). 
The client 10 can also call on the certij&cate services block to prove tliat a set of 
5 certificates provided by the service 12 actually prove that the latter has required 
attributes (proving tliis may require not only the certificate reduction functionality of 
block 21, but also the trust chain discovery functionality if the certificates are presented 
out of order)- the signature verification service of the cryptographic services block 22 
will also be needed to verify that the certificates presented check out. 

10 

SLS is a layered protocol with a base layer impleTtjented by the SLS PDU processor 28, 
the latter serving to assemble/disassemble SLS PDUs protocol layer (for example the 
key-exchange protocol operated by tiie handshake protocol engine 24 or the secure 
channel protocol operated by the secure channel protocol engine 25). The general form 
15 of the SLS PDUs is depicted in Figure 1 for a PDU 35. The PDU 35 has, in addition to 
a payload 39, a heading made up of three fields as follows: 

a header field 36 containing the receiving party's SPI for the current session, to and 
Brom addresses (in any form suitable for transport entity 14)^ and a message serial 
nniT)ber c described below; 

2 0 - a message type field 37 indicating one of the following four message types: 

HANDSHAKE 

APPLICATION (payload to be passed to ^plication) 
TUNNEL (messages for nested sessions) 
ALERT (error messages) 
25 - an encoding type field 38 indicates the security processing in force as determined 
by the current cipher suite (see below), namely, clear text, a message protected by 
a MAC or an encrypted message (also with a MAC). 

This protocol supports tunnelling, that is, the passing of PDUs through an access- 

3 0 controlling intermediate system to a final destination, for example, a gateway. PDUs 
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that are to be tuimelled are encapsulated in SLS PDUs wMch have their message type 
(fie)d 37) set to TUNNEL. Tuimelliaig requires the consent of the intermediate system 
concerned as will now be explained below with reference to Figure 2, 

5 As before^ suppose tlie parlies to the SLS handshake are Alice and Bob, widi Alice 
initiating as client. When Alice sends a handshakeStart message to Bob she is expecting 
a handshakeReply from Bob fliat includes Bob's proof of the attributes AUce required of 
him. However, sometimes Bob is not in a position to supply the proof - for example, 
consider the case where Alice has the address of a service that appears to reside at Bob, 
10 but Bob is lu fact a mediator (gateway application) for the service and forwards the 
^..^ request to another party, Charhe, who implements the service. Charlie is shown in 

tail 

Jl Figure 2 as a system 60 composed of a transport entity 61, an SLS entity 62 and a 

;f : service 63. If Bob has no security restrictions of his own he can simply forward 

i]| messages unchanged in both directions, and Alice and CharUe can set up an SLS 

%l 15 session. If necessary. Bob can rewrile the to and from addresses of the messages to get 
01 them delivered to the right place. This is because the to' and 'from' addresses are not 

':L, protected by the handshalce signatures or MACs (they are in the header field 36). 

y 1 Everyttiing else is protected. 

r 1 20 Assume now that Charhe has allowed Bob to broker the service provided by CharHe and 
also to hnpose his own access restrictions. This means that Bob wants to check Ahce's 
attributes Bob has to set up an SLS session with her. But since Bob is not tlie real 
service he may well be unable to prove to Alice the properties she requires of the 
service. This possibihty is provided for in the SLS protocol by including a 'relay flag in 

2 5 the handshakeReply message hsR sent by Bob to Alice. 

When the relay flag is true. Bob is telling Alice that he is a mediator, and so may not be 
able to prove all Alice's required attributes. It is up to Alice whetlier this is acceptable. 
If it is, she can complete the handshake and set up a session with Bob (the Alice-Bob 

3 0 session 64). Ahce now needs to set up a session with the entity Bob is relaying to 
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Charlie in this case (the Alice-Charlie session 65). Alice does this using Alice-Bob 
session PDUs of message type TUNMEL. These FDUs cany, as payload, PDUs for the 
Alice-Charlie session 65 (effectively a nested session within the Alice-Bob session). 
The PDUs for the Alice-Charlie session contain the messages (initially, haidshake 
S messages but subsequently encrypted message data), and the unencrypted PDU fields 
36-38 - since this information will be visible as such on the Bob-Charlie connection, 
there is no great benefit in Ahce encrypting the payload of the Alice-Bob session PDUs 
and this step can therefore be omitted to reduce processing overhead though forming a 
MAC for this payload should still be done. When Bob receives an Ahce-Bob session 
10 PDU with its message type set to TUNNEL, he forwards its payload as a PDU to the 
mediated entity (Charlie). Bob performs the security processing negotiated for his 
session with Ahce in the usual way. IT Bob receives a PDU from Alice with message 
type set to APPLICATION rather than TUNNEL, Bob assumes the message is for him 
and attempts to decrypt the payload of the PDU in the usual way. 

15 

Alice now sets up the Alice-Charlie session 65 with Charlie. Notice that once a secure 
channel has been set up between Alice and Charlie, then assuming Alice encrypts the 
payload of Uie Ahce-Charlie session PDUs, Bob will not be able to read the payload 
being passed to Charlie. All he will be able to see is the header fields 36-38. 

20 

hi controlling tunnelling, the control block 26 of the protocol engine 23 of Alice's 
system (the sending system) needs to keep a track of the session nesting. This can be 
done by including in the data store for each session the SPI of any immediately-nested 
session. Thus for the Figure 2 example, the session data for the Ahce-Bob session 64 

2 5 (which would generally be the session data initially retrieved by control block 26 when 
Ahce indicates she wants to send a message to Charhe) would show that the session was 
with Bob, not Charlie, and that there was a nested session with states SPI (being the SPI 
of the Alice-Chai:lie session 5), This tells the control block 26 that when sending data to 
Charlie the Alice-Bob session 64 is simply acting as a channel for a nested session with 

30 the consequence that the PDUs of session 64 should be set to type TUNNEL (the 
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question of whether or not the paylqad of these PDUs is to be encrypted can be set by 
policy, by choice of cipher suite, or by an' 'explicit flag set in the session data). The 

control block 26 next looks at the dktla for the session corresponding to the SPI in the 

I 

AUce-Bob session data, namely thd Alice-Charlie session data; this indicates that the 

i 

5 receiver is Charlie (the required recipient) so that the PDUs for this session will have a 

if 

message type APPLICATION and th|e payload will be encrypted. 

j 

If Alice wants to send a message lo Bob, tlien when the control block looks up the 
session data for session 64, it can see thai tte recipient is Bob and so PDUs can be set 

i 

10 directly to APPLICATION and there is no need to use any nested sessions; in other 
words, the control block does not need to ;concem itself with the fact that session 64 
caiiies a nested session as indicated by the session 65 SPI in the session 64 data. 
As already indicated, handhng of tunnelling by the recipient (Bob) of a PDU of the 
message type TUNNEL is very simple and! does not require any tracking mechanism - 

15 the recipient simply takes the payloald of the received PDU, carries out any MAC based 
checking need (as indicated by the|encoding type field 38) and forwards the payload 
(minus MAC, if present) to the enti^r (Charlie) indicated in tlie "to'' address included in 
the header field 36 that forms part Jf the payload of the received PDU. Of course^ the 
address of this entity is probably not known: to Alice and Bob must supply this address, 

2 0 inserting it in the "to" address of the PDU ,to be forwarded. The address of Charlie is 

;j| 

conveniently held by Bob in his session data for the Alice-Bob session ready for use 
when a TUNNEL PDU is Teceived||from alice. Bob will generally also set the "from" 

address to show that the message is from him- 

ii 



25 An intended application of the above-described SLS protocol is in providing security to 
Hewlett-Packard^s 'TB-speak" technology. It is useful in understanding the capabilities of 
the SLS protocol to consider examj^les of how the protocol can be deployed with such 

technology, A brief overview of I'^e E-speak teclmology is given below to aid an 

ji; " 

understanding of the SLS deployment; a mcjre detailed exposition of the technology can 
30 be found in ["E-speak Architectiure Specification", Hewlett-Packard Company, 

If ; 
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September 1999 available at hltp;//\^jiww.e-speak,hp.c^ 

I . 

E"Speak deals in terms of 'Resources" described by metadata. The metadata defines 

i 

resource type, attributes and security preppies. Resdurce metadata is registered witli 

il 

5 repository in an E-speak daemon Icnown as a "core"; this metadata can be exported from 

j| ' ' '■ 

core to core. An active service regJsters itself as the handler for a resource with a core 
which then forwards messages for fbi resource to the handler. For present purposes, the 
handler and resource will be treated|as equivalent to a; "service" application such as the 
service 15 of Figure 1; also, for fishnplicily, the resource mid handler will not be 

I'i ! ' 
1 0 distinguished and are jointly referredijto beloiw as a "resource". 

i ■ . : 

A chent typically comiects to a cor^, does an attribute^based look-up to find a resource 
and then is able to invoke the resource. The core passes messages from the client to the 

Si 

resource. All resources are referred to by name. 



The SLS layer is intended to form a! 



[part of an E-speak core to provide security (access 



control and confidentiality) for comihunication betweati a client and a resource. Figure 

I 

3 depicts this situation where a client end systeiji 80 communicates with a resource 
CI system 8L The client end system comprises the* chent apphcation 82. Similarly, the 

20 resource system comprises a resourcie 86, an E-speak core 87 with SLS layer 88, and a 
h - transport entity 89. The E-spcak corps arc shown hatched for clarity. The ftmctionahty 

provided by the E-speak cores 83, 87 in addition 'to that provided by the SLS iayer^ is 
represented by respective services j blocks^ 90 and 91; this additional functionality 
includes resource registration, metadata export, and resource discovery. Once tlie client 
25 82 has determined by reference to|||core services 90 that resource 86 can provide a 
desired service and is likely to allow the client access, the chent can seek to estabKsh a 
secure session with resource 86 asing the sei-vices of ttie SLS layers S3 and 88 in tlie 

manner previously described, .15 

ti 



1: 



3 0 The client and E-speak core may ndjt, however, always reside on the same end system. 
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For example, a client may simply be a small application 93 running in a web browser 94 
(see Figure 4) with the most convenient E-speak core 95 being one hosted by a broker 
system 96 connected to the web. By providing browser 94 wjth an SLS XML plug-in, 
client 93 can establish a secure session 97 over an HTTP connection with broker 
5 application 98 running on system 96 and make usej of core 95 to locate a target resource 
100. The cUent can then establish a nested spS5ion|l01 with the resource 100, turmelling 
through the broker system; the connection between the broker system and the system 
ninning resource 100 is, for example a TCP connection. Of course, setting up the 
sessions 97 and 101 requires the psolicipating partijes to prove required attributes to each 
1 0 other in the manner already explained when descriliing the SLS protocol. 

I 

,1 

^1 1 The above is but one approach to providing a communications channel between a client 

and a service provider and one to which ^ttie present invention, which will now be 
Pl described in detail, is particularly applicable. However, it will be appreciated the 

J:! 15 method of the piesemt invention is not limited | to use with such an approach just 
y1 described. ' j 

si 1 

I 1 

111 Referring now to Figure 5, a service proviker 60 [wishes to expose a service, Servicel 

Tun on core machine 64 having real name saile-m-l.hp.com bound to IP address 

C:l 20 15.144.27.212. In accordance with the present invention the path of Servicel is made 
known to excemal chents as servicel .lipxcm/root/sen^iccl by allocating a virtual name 
service Lhpxom as the service provider and advertising it on the external network as the 

only reference to Servicel by any suitable means- In this particular example, the 

'i ' ■ 

external network is assumed to be the internet arid .£he virtual name servicel.hp.com is 

2 5 advertised on the external DNS 66 and bound tc| the. real name of gateway 13, hi this 

case gateway-hp.com in turn bound to IP addiessj 15.255.59,2, The same virtual name, 
servicel.hp.com, is also advertised on an it^temal [dNS 68 but is bound to the real name 
of the core 64 namely salle-m- Lhpxom. j That is, Servicers virtual name 
service Lhpxom appears as a CNAME on the!, outside and inside DNSs 66,68 to 

3 0 gateway.hpxom and salle-m- Lhpxom, respectively. An exemplary access to this 
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senrvjce, Semcel (63), by the client 10 will now bd described with reference to Figure 6 

The client 10 in this example first searches for a relevant seivice to meet their 
requirements by querying a public search service pO with query {vccab 1, att 1, att 2} 
via the internet. The ' i advertised virtual name URL 

<scheine>://sendcel.hp.com/root/servicel is returned to the client 10. The client 10 
then opens a TCP connection to <schemc>:/;]serviceLhpxorr!/root/seivicel which 
implies a look-up of its IP on the extemal DNS 66 which provides IP address 
15.255.59.2, the IP address ofthe gateway 1^. | 



With reference now to Figure 1, also, the!' client 



10 then opens a TCP connection to 



15,255,59.2, step 80^ and sends its first SLS'message, The gateway 13 sends back to liie 
chent 10 the second SLS message 84 which incliuies a set "relay" flag meaning that the 
current end point is not the one expected by the client 10 but flie gateway 13. A list of 
tags that the client has to prove is also included inlthe second message. The chent 10 
then sends a tliird message 84 and at this poiint the first SLS session is established. 



The chent 10 then sends the first message 86 of a second session tunnelled in session 1 , 

I' 

which the gateway 13 knows is addressedito semcel .hp.com, as it can read the header 
fields of the message 86 (the client having addressed the message to servicel). The 
gateway now looks up servicel .hpxom on the int^al DNS 68 at step 88 and by virtue 
of it being CNAME for sal1e-m-l .hp.com iS' provided with the IP address for the core 64 

' !. I 

of 15.144.27.212. The gateway modifies the "fi-om" -field ofthe message and relays it to 
servicel (salle-m-l.hp.com/root/servicel) aistep ^0. 



Servicel 63 sends a second session 2 message 92 to the gateway 13 which forwards it to 

the chent 10 step 96 who then sends a thirdllSLS message back to servicel at step 98 via 

ii f 

the gateway 13 to estabhsh session 2. The siession! between the client 10 and service] 63 

i I 

is then established and there now follows 'application messages 98 between them. The 
client 10 can now exchange end-to-end secure messages with the service provider of 
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Servicel. 



66 is used. When the client sends 



5 servicel .hp. com in the outside DNS 66 and finds 



17 



Figure 8 illustrates how the gateway 13 mayibe configured when only one exposed DNS 



iao24 



a message to Servicel 63, he looks up the URL for 



a CNAME, gatewaylip-com, and is 
15,255.59-2. The client's message is 



then provided with the IP address of tlie gateway, 
routed to 15,255,59.2. On receipt of this message, the gateway 13 looks up 
serviceLhp.com in its intemal naming service 100 anid finds sallc-m-l.hp.com- The 
gateway 13 then looks up tlie IP address of salle-m-1. hp.com in the external DNS 66 
and finds 15.14427.21 2 and then opens a connection to 15.144.27.212. 



Figure 9 illustrates an embodiment in which a further service reference is passed from 
the service provider to the client lO, first ithe client 10 accesses servicel through the 
gateway using its YN (<scheTrie>://servic'el .hp.com/root/servicel), and invokes the 
Servicel as described with reference to Figure 6. As a result of this invocation, Servicel 
instantiates a new service and registers it as! Servicel -1 with /root/servicel-1 as the path 
on both the intemal and external DNSs- Servicel then returns the complete Servicel-l 
URL, that is to say <scheme>://serviceli.hp.com/root/servicel-l, to the chent 10. 
Finally, the client accesses Servicel-1 lhrc>ugh the gateway 13. In this embodiment, 
client 10 is behind its own gateway 102 bridgirfg the client's private network to the 
internet. 

Tu rnin g now to Figure 10, there is illustrated how client-side call-backs can be handled 
according to the present invention The network arrangement is as in Figure 11 and in 
which tlie client 10 is on a private network having a server provider core with real name 
pr,xyxom providing a service, SeTvice2 100 having path /root/service2. The internal 
network of chent 10 is bridged to ,the internet by the .gateway 94. 



CUent 10 accesses Servicel in the 



manner described with reference to Figure 9- In this 



30 case, the client 10 passes to Service] a virtual n; 



le reference Service2 rimning on the 
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client's 10 domaiTi, namely <scheme>://servicel.xy.com/root/service2. Access to 
Service2 by Servicel is also according to the present inveBtion, in that the virtual name 
service Lxyxom is bound on the external network to gateway.xy-com, the real name of 
the gateway 94, and is bound to pr.xy.com on the internal network of chent 10, the 
virtual names being advertised on the ;ext!3mal DNS 66 and an internal DNS 102, 
respectively. 

Figure 11 illustrates a variation of the ihteractions. illustrated in Figure 10 in which a 
second service, Service2 110 is provided by a service provider not on the internal 
network of client 1 0 but on a furllier internal network behind gateway 112 bridging that 
internal network to the inteniet 92. 

First client 10 access Servicel using its virtual name servicel .hp.com the access being 
relayed by gateway 98 according to the present invention and as described with relation 
to Figures 5 to 9- hi this case it wjjl be assumed Servicel is a search engine and that it 
returns the URL of a matching service, Sersdce2, 110 available &om a server with real 
name pr.ab.com behind a gateway 112 with real name gateway.ab.com. The URL 
advertised by the service provider HOis the' virtual name servicel. abxom/root/seTvice2, 
with service Lab xom being bound to real name giiteway.ab.com on the external DNS 66 
and to pr,abxom on a DNS 114 internal to the service provider 1 10, in accordance with 
the present invention. The chent 10 can th^n connect to Service2 behind gateway 112 
analogously to the method of connecting to Servicel. 



Turning now to Figure 12, there is 



25 can connect via die internet 92 again, in this example/ to a service^ Servicel 202 across 



multiple enclaves demarcated by a 



shown a network arrangement in which a chent 200 



series ofthree gateways 206,208,210 with respective 



real names gl-l5),com, g2,hpxom and ^Jip.com and respective IP addresses of 

I : 

15.255,59.2, 15J3639.4 and 15.112.23,2. | The externa] network 92 and the network 

behind each gateway 206^208,21,0 has associated with it a respective DNS 66, 

i 

212,214;216. The service provider of Servicel, in accordance with the present 
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invention J advertises the same virtual name the service provider has allocated to 

I 

Servicel (serviceLhp.com) on each internal DNS 212,214,216 and external DNS 66. La 
each case it is set as an alias (CNAME) for the respective gateway real name on the 
DNS of tlie network immediately external to :the respective gateway. 

The virtual name servicel. hpxom therefore provides a global address which can be 
used, unchanged, to define a routing path frbm the client 200 to the required Servicel at 
real name prhp.com on the internal nel-work behind the gateway 210, 



10 



